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Abstract. Despite the effort of many researchers in the area of multi-agent systems 
(MAS) for designing and programming agents, a few years ago the research commu- 
nity began to take into account that common features among different MAS exists. 
Based on these common features, several tools have tackled the problem of agent 
development on specific application domains or specific types of agents. As a conse- 
quence, their scope is restricted to a subset of the huge application domain of MAS. In 
this paper we propose a generic infrastructure for programming agents whose name is 
Brainstorm/J. The infrastructure has been implemented as an object oriented frame- 
work. As a consequence, our approach supports a broader scope of MAS applications 
than previous efforts, being flexible and reusable. 
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1 Introduction 



Intelligent agents are one of the most rapidly developing areas of research of the last years. 
Agents offers new ways to analyze, design and implement software systems, improving, 
potentially, the ways in which software is modeled and materialized. 

A pplications of intellig ent agents are surprising var ied: from simple personal assis- 
tants ( Mitchell et al., 1994 ), mobile robots ( Brooks, 1986| ) and Internet agents (Etzioni and 
Weld, 1994), to complex autonomous propulsion system s for the space shuttl e (Georgeff 
and Ingrand, 1989), assistants for software development ( Drtigosa et al., 19*9^ ) and agents 
for process scheduling in industrial systems (Fischer, 1994). On the other hand, agents can 
carry out this variety of activities in different ways ( Wooldridge, 1998): interaction with 
people and/or agents, reactivity, deliberation, representation and manipulation of mental 
states, and mobility, among others. 

The construction of agents involves several steps from their conception to the execution 
of code. In order to make easier that process, models ( Rao and Georgeff, 199 it Shoham, 



1993), architectures 
and methodologies ( 


;Muller, 1996|; 


Georgeff and Ingrand, 1989 


; |Amandi and Price, 1998) 


Demazeau, 1998; 


Drogoul and Zucker, 1998; Wooldridge et al., 1999) 



have been proposed. 

Models define a general structure and the relationships among the main components; 
software architectures gives more detail, specifying how the components interact through 
specific protocols; finally, methodologies define steps to follow using models, architectures 
and so on for building applications. 

Concerning to architectures, many agent architectures have been proposed in the litera- 
ture. Several of them can be classified as software architectures since they prescribe an im- 
plementation. We can mention Interrap ( Miiller, 1996| ; Fischer et al., 1996), ARCHON (Jen 



Amandi and Price, 1998) among them. 



nings, 1994; Cockburn and Jennings, 1996), and Brainstorm (Amandi and Price, 1997 



Software architectures (Shaw and Garlan, 1996) prescribe an implementation as a spec- 
ification of components and interfaces. Developers using these software architectures im- 
plement the components and then connect them through the specified interfaces. Thus, 
developers have a reusable design in a high level of abstraction to develop their multi-agent 
systems. 

Taking an architecture as a base, a code scheme can be built providing to the developer 
the common code of those architectural components. This code scheme is named frame- 
work (Johnson and Russo, 1991) by the object-orientation community. 

A framework is defined as a set of classes that implement the common flow of con- 
trol among objects in a schematic way. A framework of agents allows the construction of 
multi-agent systems by subclassification and composition of this set of classes. Classes 
built by subclassification implement the behavior related to a particular application being 
built. Moreover, the functionality provided by a framework can be extended by means of 
subclassification. 

In this paper, we present a framework for multi-agent systems named Brainstorm/J that 
is based on the Brainstorm architecture ( A.mandi and Price, 1997; Amandi and Price, 1998). 
This architecture allows simple objects to be extended to become agents. The extension is 
supported by meta-objects (Maes, 1987), which represent a flexible and adaptable way for 
composing components. 

The paper is organized as follows. Section ^ briefly describes the Brainstorm architec- 
ture. Section || presents the framework Brainstorm/J. In this presentation we show how a 
new multi-agent application reuses both common components and control flow specified in 
the framework. Section ^ discuss our experiences with the framework. After that. Sect. || 
describes some related work. Finally, Sect. || presents the conclusions. 



2 Brainstorm 

The backbone of Brainstorm/J is a class hierarchy with a small number of abstract classes 
that have been built based on the design of the Brainstorm architecture (Amandi and Price, 



1997; Amandi and Price, 1998). This section briefly describes the organization of the ar- 
chitecture and its components. 

The conception of the Brainstorm architecture is supported on the fact that a multi- 
agent system (MAS) can be considered as an object-oriented system that has associated a 
meta-system (Amandi and Price, 1997; Amandi and Price, 1998| ). This meta-system incor- 



porates typical agent behavior to simple objects. Then, an agent is considered as an object 
with a layer of intelligence in the meta-level. Thus capabilities such as communication, 
perception, reaction and deliberation, that are not inherent to objects, can be introduced in 
a meta-level. 

For providing agent capabilities to objects, the Brainstorm architecture prescribes the 



usage of meta-objects. A meta-object ( Maes, 1987 ) is a special object that has the ability of 



intercepting the invocation to methods, altering thus their execution. In this way, a multi- 
agent system is defined as an object-oriented system in which some objects that are consid- 
ered agents have associated a meta-level with agent capabilities. The set of meta-levels of 
the objects considered agents compose a meta-system. This meta-system is a reflective sys- 
tem causally connected to the object-oriented system defined in the base-level. The causal 
connection is established when an object receives a message. If the object has been defined 
as an agent, the message is intercepted by the meta-level, which decides what to do with 
the message. In this way, for example, an agent can decide to deny a request of another 
agent or to initiate a planning algorithm to achieve its goals. 

Brainstorm allows each object to have several meta-objects associated. The amount of 
meta-objects associated to an object depends on the required agent functionality. Therefore, 
the selection of a set of meta-objects for an object allows the developer to define different 
types of agents such as reactive, deliberative or hybrid agents. 



Figure [T](a) shows a scheme of the architecture. We can observe that an object has 
several meta-objects in different levels. In the first level, four types of meta-objects are 
defined: creation, perception, communication and knowledge meta-objects. In the second 
level, two types of meta-objects reflect the behavior of the meta-objects of the first level: 
reaction and deliberator meta-objects. Finally, in the last level, learner meta-objects can be 
added. 

The communication system (messages) is uniform enabling objects and agents to work 
together. Interaction among agents is established through messages or indirectly through 
perception. An object acquires these capabilities by associating meta-objects to it. 

The communication meta-object defines the communication language used by an agent. 
The messages received by the agent's object are intercepted by the associated communi- 
cation meta-object. In this way, any object can acquire the capability of using an agent 
communication language such as KQML or FIPA's ACL. 

An agent can also perceive changes in its environment. This is achieved by means of a 
set of perception meta-objects. A perception meta-object observes the behavior of an agent 
or an object, detecting the invocation to methods. Thus, it records any event of interest. For 
example, an agent A would like to perceive the communications received by an agent B 
from agent C. Then, agent A defines a perception meta-object for B, indicating what it shall 
observe. Thus, an agent can transparently perceive events taking place in its environment. 

The knowledge meta-object is responsible for mental states. It provides facilities for 
managing knowledge expressed as logic clauses. This capability is possible since an in- 
tegration of an object-oriented language with a logic language has been defined (Amandi 
et al., 1999). The goal of combining objects and logic is to provide a support for allowing 
objects to define and use mental states represented as logic clauses. Moreover, mental states 
can be represented as objects, clauses or clauses composed by objects. The combination al- 
lows objects to: define mental states in instance variables, define mental states in methods, 
refer to mental states in methods, represent mental states as logic clauses and objects, and 
inherit mental states among classes. 

Agents define their behavior by associating meta-objects of type reactor and/or deliber- 
ator Reactors and deliberators intervene in all messages that support interaction. When an 
agent perceives something (through some perception meta-object) or receives a message 
(intercepted by its communication meta-object), an interesting situation can be detected. 
Then, the reactor and/or the deliberator meta-objects intervene, reacting and/or deliberat- 
ing. 

The reaction of an agent involves the immediate execution of different activities that can 
be basic actions defined in the associated object, a change in agents' beliefs, a message to 
other agent, etc. An agent's deliberative process involves carefully thinking before making 
a decision about what to do next. 

In the last level of the architecture, a learner component is defined. Meta-objects inter- 
vene in deliberative processes to help in decisions. Regarding to the reaction process, these 
meta-objects can alter some reactions. 



3 The Framework Brainstorm/J 

For developing multi-agent systems, it is necessary to have an appropriate agent-oriented 



support (Jennings et al., 1998). Additionally, it is very convenient to make use of software 



components that permit to compose complex agent behaviors (Amandi and Price, 1997) to 
build different types of agents. To achieve these goals we have developed an object-oriented 
framework based on the Brainstorm agent architecture. 

The Brainstorm architecture prescribes mechanisms for defining agents through a set 
of meta-objects. Based on Brainstorm we have defined a set of agent components by means 
of Java classes that can be specialized for building particular agents. 
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The framework has been implemented by using JavaLog, a multi-paradigm language 



based on Java and Prolog ( \mandi et al., 1999), and a meta-object support for Java based 



on LuthierMOPS (Campo and Price, 1999) 



This section is structured as following. First, we describe the materialization of the 
architecture in the framework. Then, we define details of several classes of the framework. 

3.1 Mapping architectural components into classes 



The framework Brainstorm/J ( Zunino, 2000 ) has been built from the Brainstorm architec- 
ture. Figure |l] shows the materialization of the architecture. It presents the mapping from 
architectural components to classes. 

Figure |l](a) shows a basic scheme of the architecture. In Fig. |l](b) several direct mapping 
from architectural components to classes are visible: a base object, a situation manager, and 
several meta-objects such as perceptors, deliberators, reactors, learners and meta-agents. 

Architectural components related to communication and knowledge management are 
materialized by using more than one class. The communication component is materialized 
by two classes, a communicator meta-object and a mobility object. 

The knowledge management represented by the architectural components LogicKnowl- 
edge and Brain is materialized by means of the multi-paradigm language JavaLog (Amandi 
et al., 1999). This language integrates object-oriented programming with logic program- 
ming. 

3.2 Creating an agent from an object 

Brainstorm prescribes an architectural component named MetaAgent, which is responsi- 
ble for agent creation and initialization. This component is able to create different types of 
agents (reactive, deliberative, hybrid, etc.) with diverse agent capabilities (reaction, percep- 
tion, communication, etc.). 

In Brainstorm/J, MetaAgent has been materialized by two classes: MetaAgent and 
BasicAgent. The first one is in charge of agent creation. The second one is responsible 
for initializing the components of an agent components and keeping information about it. 

Agents built with Brainstorm/J are composed by an object living on the base-level, and 
some objects and meta-objects situated on meta-levels. The object situated on the base- 
level represents an agent's basic skills or capabilities. These skills can be considered as the 
effectors of the agent or its devices to modify the environment. Note that these skills do 
not include intelligence at all, since intelligence is added by associating meta-objects. In 
order to create agents, every MetaAgent meta-object is associated to some class situated 
on the base level. Then, objects belonging to classes with an associated MetaAgent are 
agentified immediately before their creation. 

To clarify the process of agent creation we will describe a multi-agent system named 



FORKS (Mtiller, 1996) which has been implemented with Brainstorm/J. The system con- 



sists of a set of forklift robots, which try to move a number of boxes from a truck to some 



shelves, as shown in Fig. 2(a) . Each robot has a number of basic skills such as advance, 
turn to some direction, grasp a box situated in its front, put a box and perceive its environ- 
ment. These skills are represented as methods of class Forklift. It is worth noting that 
this class represents only the basic skills of a forklift. That is, objects of this class are not 
agents, since they do not have agent capabilities. 

In order to create agents having instances of Forklift as base-objects, we have as- 
sociated a meta-object of class MetaAgent to Forklift. Figure 2(b) shows a meta- 
object called aMetaAgent associated to the class Forklift. This meta-object is ac- 
tivated when Forklift receives a message for creating a new instance, for example 
aForklift. The activation of the meta-object triggers the creation of a set of objects 
and meta-objects defining agent capabihties such as perception, reaction, communication, 
mobility, deUberation, etc., depending on the desired agent capabilities. Then, these objects 



and meta-objects are initialized by an instance of BasicAgent. Finally, the meta-objects 
are associated to the base-object aForklif t, adding agent capabilities to it. 




(a) The FORKS applica- (b) Agent creation 

tion 

Fig. 2. The FORKS multi-agent system 



Since objects and meta-objects which belong to the reflective level are in charge of 
agent capabilities, some of them can be optional. For example, a reactive agent does not 
use a deliberator object since its reactive behavior is encoded into a reactor object. 

In order to support different types of agents, MetaAgent provides a number of meth- 
ods which can be used by the programmer to specify the capabilities of agents to be cre- 
ated. For example, the hasReaction method invoked with a true argument means that 
agents created by a MetaAgent meta-object have reactive capabilit^j]. 

The basic idea to capture the agent creation process in an application independent way 
consists of implementing that functionality into a so called t emplate method. A template 
method ( lohnson and Russo, 1991 ; |^ayad and Schmidt, 1997 ) is a method that specifies an 
operation in an application independent way, describing the flow of control among a set of 
objects. The feature that distinguishes a template method from other types of methods is 
the fact that a template method always invokes to several abstract methods. 

An abstract method can be considered as a hole into the framework, which should be 
completed by the programmer with the application dependent functionality. It is worth 
noting that template methods provides a way to program operations in an application inde- 
pendent way. At the same time, they can be customized by defining abstract methods. 

As an example of a template method. Fig. 2(b) shows a class diagram with a template 
method named createAgent. It invokes the abstract method initCommunication 
declared in the abstract class Communicator. In a concrete subclass of Communicator 
named KQMLCommunicator, the initCommunication method is defined. 



3.3 Perception 

Perception capabilities of agents are implemented by class Perceptor. This class is a 
type of meta-object, thus its instances are meta-objects capable of intercepting messages 
between objects transparently. Note that perception usually refers to detecting changes in 
the environment. Here, the environment as well as other agents are represented by objects 
and meta-objects. Therefore, it is possible to detect changes in these entities by intercepting 
message between objects. 

The class Perceptor defines the common functionality of perception. A meta-object 
of this class is notified with messagePerceived when an interesting message is re- 

' Instances of MetaAgent can be considered as a class of agents. 
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ceived by one of its perceived objects. Programmers can redefine that method to pro- 
cess each perceived message according to their requirements. By defauh, that method 
notifies to a Situation Manager object about every perception, giving it opportu- 
nity to detect interesting situations. A typical usage of perception consists of redefining 
me ssagePer ceived to add and update agents' beliefs according to perceived messages. 

While other approaches for perception based on the observer design pattern (Gamma 
et al., 1995) require an agreement among objects on a common protocol for message in- 
terchange, our approach does not, being capable of perceiving any message on any object 
without neither modifying its class source code nor requiring any common message proto- 
col. 



3.4 Situations 

A situation is an interesting event for an agent. When a situation occurs, an agent can re- 
act quickly or analyze carefully its future actions. Interesting situations are detected by 
a SituationManager object when a message is perceived or a communication is re- 
ceived by taking into account an agent's mental states such as beliefs, knowledge and goals. 
Brainstorm/J represents situations by means of a set of logic clauses contained into 



a logic module ( A.mandi et al., 1999 ). As an example, we show how to define a simple 
situation called boxInFront. This situation occurs when a box is at [X^Y] such that {X,Y) 
is in the front of a robot. This situation is expressed as follows: 

situation (boxInFront , Box) :- 

location (box (Box) , X, Y) , #Box is at X, Y 

newlnstance (' java . awt . Point ' , [X, Y] , Front) , #Front=(X,Y) 
baseOb ject (Base) , #Base is the base object (Forklift ) 
send (Base, nextLocation, [], Front) . 

in this clause, location(box(Box), X, Y) denotes that Box is at {X,Y)\ newlnstance('java. 
awt. Point', {X, Y ], Front) means that Front is an instance of Point equals to {X,Y); 
and baseObject(Bfl5e) means that Base is the base object of an agent. As a consequence, 
situation(boxInFront, Box) is true only if Box is at front of a robot. 



3.5 Deliberation 

Brainstorm prescribes an architectural component for dealing with deliberation: carefully 
analyzing future actions in order to achieve a set of goals. The implementation of this com- 
ponent has been done taking into account that agents should be able to perform several 



activities concurrently. For example, an hybrid agent should be able to perceive its envi- 
ronment reacting accordingly while engaged in a dialog with other agents and reasoning 
how to achieve its goals. Moreover, agents should be able to reason about how to achieve 
their goals by using several concurrent reasoning mechanisms and taking into account the 
effects of environmental changes in the reasoning process and dependencies among differ- 
ent reasoning mechanisms. For example, while building a plan, a belief can change as a 
consequence of perception; an agent should analyze how this new belief affect the plan, 
repairing it if necessary and analyzing possible dependencies among its internal tasks. 

To support these features, Brainstorm/J assigns to every internal agent component its 
own thread. Moreover, the deliberative process is performed by several concurrent objects 
that are able to: perceive any activity within an agent such as a commitment to a goal, a 
new perception, an achieved goal, a produced plan, etc^; produce actions and partial plans; 
take an akeady produced action or plan to execute or modify it, interact with other objects 
by means of events such as kill, wait, achieve a goal, etc^. 

Brainstorm/J defines several types of objects for reasoning. Among them, the most 
important are: PlanProducerKS produces a partial plan for achieving a goal, class 
DelibStrKS uses a generic planning algorithm as GraphPlan (Blum and Furst, 1997) 
or any user defined algorithm for producing partials plans. Executor executes actions or 
plans produced by other objects, AbsPlan groups related objects into partial and incom- 
plete plans representing a course of action for achieving a goal, PlanAdapter defines 
generic services for adapting partial plans, DistanceReductionKS produces actions 
for reducing the distance to a goal, etc. 

To clarify the concepts introduced in this section we describe the design of some classes 
of Brainstorm/J which define a simple deliberative mechanism. A deliberative agent decide 
which actions execute based on its goals. There are many decision mechanisms that can 
be used to accomplish this task, for example, off-line planning, on-line planning or rules. 
A tool can provide a highly generic mechanism such as a planning algorithm to do so. 
Quite certainly in some applications the algorithm would not be capable of handling appli- 
cation specific constraints or to take into account information that would lead to a better 
performance. The approach used to design Brainstorm/J is different. Instead of providing 
a generic mechanism to deliberate, it defines a flexible infrastructure to build decision pro- 
cedures for goal-directed behavior. 

Figure ^ shows a diagram with some classes of Brainstorm/J in charge of delibera- 
tion. The abstract class DistanceReductionKS can be used by a deliberative agent 
to achieve its goals. The class defines a template operation named getPlan to reduce 
the distance to a goaQ. The class also defines two abstract operations: distance and 
getPlanFor. The idea here is that different agents will have completely different ways 
of measuring the distance to a goal and to build a plan in order to reduce that distance, so 
these are hot-spots. Note that the getPlan operation invokes these two hot-spots in order 
to build a plaqj. As a consequence, this method can be adapted by defining the two abstract 
methods (hot-spots). 

A subclass of DistanceReductionKS that defines the two abstract methods will be 
able to use the getPlan method. For example, GotoXY defines distance to calculate 
the distance between an agent and a given point in a two dimensional space; getPlanFor 



^ There are more than 30 different events related to the internals of an agent which can be used by 
reasoning objects. 

^ There are more than 20 different events related to interaction among reasoning objects. 
For example, an agent in a two dimensional grid can use the Euclidean distance between its actual 
position and its goal, an agent in Internet can measure the number of sites between its actual 
position and its target taking into account the traffic, delays, etc. 

^ This is different from traditional AI planning, since the output of the algorithm is not a complete 
plan to achieve a goal, but steps (set of actions) to reduce the distance between the agent and its 
goal. This differs from lA planning from that a step is built and executed until the goal is achieved 
or dropped, unlike traditional lA planning, execution and planning are interleaved. 
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Fig. 4. Reusing agent behavior defined in template methods 



produces two actions (rotate and advance one step) in order to reduce that distance. There- 
fore, multiple invocations of the getPlan operation will produce a complete course of 
actions to achieve a goal. 

As shown in the example, programmers using Brainstorm/J deal only with application 
dependant functionality by defining abstract methods. This is as a consequence of the usage 
of template methods defining the common functionality of agents. 

3.6 Reactive behavior 

When an interesting situation is detected by a Situat ionManager object, an agent can 
react in a predefined manner. In order to react, an agent uses a Reactor object and a set 
of reactions (class Reaction). 

A Reaction is composed of two parts: a precondition and an agent's basic skill rep- 
resented by a method of the base object. When a situation occurs, the Reactor object 
checks all the reactions executing only those whose precondition is true. Figure || shows a 
reaction called BoxInFrontReaction to the boxInFwnt situation defined previously. 
This reaction executes an action named gmspBoxO as a response to boxInFwnt situation. 
The action graspBoxO succeeds if the agent is not holding a box. As a result of the execution 
of graspBoxO, the box is no longer on the floor, but is held by the agent. 
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Fig. 5. A reaction to the boxInFront situation 



3.7 Communication and coordination 



Brainstorm/J supports the construction of agents which communicate robustly over a LAN 
by using several protocols such as e-Mail, TCP/IP or HTTP; diverse agent communication 



languages such as IL (Demazeau, 1995), KQML (Finin et al., 1994) or FIPA's ACL (The 



Foundation for Intelligent Physical Agents, 1997); and multi-agent coordination through 



COOL-like (Barbuceanu and Fox, 1999) conversations 



An agent composed by a Communicator object is able to interact with other agents. 
This class only defines an abstract interface for communication, so programmers should 
extend it according to their requirements. In addition, Brainstorm/J provides a concrete 
class for communication by using KQML. The concrete class KQMLCommunicator is 
able to send KQML messages through the Internet by using TCP/IP, SMTP/POP (e-Mail), 
FTP or HTTP 



Services provided by KQMLCommunicator are built by using JATLite (Petrie, 1996). 
As a consequence, all communications pass through a centralized component called Agent 
Message Router (AMR). The AMR also provides name services, brokering and off-line 
operations. 

Brainstorm/J provides several classes for responding to KQML performatives in a de- 
fault manner. For example, class AskOneHandler can be used for responding to all 
ask-one messages in a given content language and ontology. This class verifies whether 
the content of an ask-one message can be deduced from agent's mental state and re- 
sponds accordingly. 

The framework supports coordination by means of COOL ( Barbuceanu and Fox, 1999| ) 
conversations. A conversation is specified by a conversation class and a number of conver- 
sation rules. A conversation class defines a set of interactions among agents. Each possible 
interaction in a given point of a conversation is described by conversation rules. 
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(a) A simple conversation class 



(b) Conversation classes and conversation 
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Fig. 6. Coordination using COOL-like conversations 



A conversation can be represented as a definite finite automata (DFA). Each state of 
the DFA represents a st ate o f a conversation; each transition is equivalent to a conversation 
rule. For example. Fig. |6(a)| shows a simp le conversation class belonging to a mult i-agent 
implementation of the n-Queens problem ( Chauhan and Baker, 1998| ; |Zunino, 200C ). 

A conversation rule relates two states of a conversation. As shown in Fig. |5(b)| a conver- 
sation rule occurs when some event activates that transition (suchThat method). When a 
transition occurs, actions attached to it are executed (doBef ore and doAf ter methods) 
and a message is sent (sendMessage method). This process is described by the check 
template method of the class ConvRule. Figure |6(b)| shows a class named Ml which 



defines the abstract methods of ConvRule to represent the rule Ml of the conversation 
shown in Fig. 6(a) 



4 Experiences using the Framework 



Brainstorm/J has been used to develop two multi-agent systems: Forklifts and n-Queens. 
The first MAS consists of a set of forklifts which tries to arrange a set of boxes. This MAS 
has been used to test different agents' behaviors such as random walker, reactive planning 
and heuristics for conflict resol ution. Moreov er, Forklifts has b een used to test several ag ent 
architectures such as Interrap ( Miiller, 1996 ) and Brainstorm ( Amandi and Price, 1998 ). 

On the other hand, the n-Queens system is a multi-agent solution to the n-Queens prob- 
lem. In this MAS, each agent represents a queen with the sole objective of finding a safe 
position. Each agent is assigned to a column and is able to move freely along it. Further- 
more, agents communicate among them by using KQML. 

The n-Queens MAS has been used for comparin g Brainstorm/J with other agent frame- 
work called JAFMAS ( [Chauhan and Baker, 1998 ). In order to compare both implemen- 
tations we have used several source code metrics such as non commenting source state- 
ments (NCSS), number of methods and classes, NCSS per class, NCSS per method and 
cyclomatic complexity number (CCN) (McCabe, 1976). Table |l] summarizes the results 
obtained by these code metrics. In the column difference we can observe that the imple- 
mentation made with Brainstorm/J is simpler and shorter in terms of source code, than 
the one made with JAFMAS. It is important to take into account that these results are not 
concluding, since they only show a tendency in favor of Brainstorm/J. 

Related to performance, both implementations shown very similar numbers, despite the 
usage of meta-objects in Brainstorm/J. This is a consequence of the usage of the framework 
JMOP, which introduces invocations to the meta-level by modifying Java byte-codes, and 



meta-object managers (Campo and Price, 1999) to manage the associations among objects 
and meta-objects. 



Table 1. Comparison between two implementations of the n-Queens problem 





JAFMAS 


Brainstorm/J 


Difference 


Classes 


18 


21 


14.28% 


Methods 


92 


87 


-5.43% 


NCSS 


625 


491 


-21.44% 


Methods per class 


5.11 


4.14 


-18.98% 


NCSS per class 


34.72 


23.38 


-32.66% 


NCSS per method 


6.79 


5.64 


-16.93% 


Average CC per method 


1.57 


1.51 


-3.82% 



5 Related Work 



There are currently several tools for building agents. Among them, we can mention Agent- 
Builder ( [Reticular Systems Inc., l"999|), DEC AF ( praham and Decker, 1999|), JAF (Horling, 

1998), JAFMAS ( [Chauhan and Baker, 1998D and JAFIMA ( [Kendall et al., 1999|). 

AgentBuilder ( [Reticular Systems Inc., 1999[ ) and DECAF ( [Graham and Decker, 1999[ ) 
are toolkits for building MAS based on a set of Java classes which implement common 
services such as communication, coordination and reasoning. Although they provide some 
mechanisms for adding user-defined code, they lack the flexibility and adaptabiUty pro- 
vided by our framework. JAFMAS ( [Chauhan and Baker, 1998 ) is a Java framework for 



building MAS based on a COOL-like model of coordination. As the other tools it cannot 
be extended. 

JAFIMA (Java Framework for Intelligent and Mobile Agents) ( Kendall et al., 1999 ) 
takes a different approach from the other tools: it is primarily targeted at expert developers 
who want to develop agents from scratch based on the abstract classes provided, so the 
programming effort is greater than in the other tools. The weakest point of JAFIMA is 
its rule-based mechanism for defining agents' behavior. This mechanism does not support 
complex behaviors such as on-line planning or learning. Moreover, the abstractions for 
representing mental states lack flexibility and services for manipulating symbolic data. 

At this point, we would like to emphasize the differences between frameworks and an- 
other related technique for software reuse: component libr aries. Compone nt libraries are 
being used to support agent development in tools like JAF ( [Horling, 1998| ). A component 
library consist of a number of reusable program building blocks such as C functions, classes 
or JavaBeans. As shown in Fig. ^ developers using a component library should combine 
a number of components in order to build an application. This is achieved by writing al- 
gorithms^ that call methods or functions provided by the component library in order to 
establish interactions and collaborations among these components. 




A framework as Brainstorm/J is not just a collection of components but also defines a 
generic design. When programmers use a framework they reuse that design and save time 
and effort. In addition, because of the bidirectional flow of control frameworks can contain 
much more functionality than a traditional library regardless if it is a procedural or class 
library (Fayad and Schmidt, 1997). 

None of the analyzed tools in this section handle concurrency or asynchronism within 
agents. On the other hand, agents built with Brainstorm/J are able to maintain several con- 
versations, plan how to achieve its goals and perceive its environment, all of them con- 
currently and taking into account possible interdependences and conflicts among these 
process. 



6 Conclusions and Future Work 

In this paper a framework for MAS named Brainstorm/J has been described. This frame- 
work is based on the Brainstorm architecture. As a result, it supports different types of 
agents with capabilities such as perception, communication, symbolic manipulation of 
mental states, mobility, reaction and deliberation. 

The framework has been built by using a support for meta-objects for Java named JMOP 
and a multi-paradigm language named JavaLog. It is worth noting that meta-objects pro- 

^ The composition can be assisted by a visual tool. 



vide a convenient and flexible mechanism to combine agents' capabilities to develop dif- 
ferent types of agents. Moreover, it is possible to integrate new agents' capabilities into the 
framework by adding meta-object classes. 

Brainstorm/J defines the common functionahty of agents in abstract classes. As a re- 
sult, programmers deal only with application specific functionality, since the functional- 
ity common to all types of agents is reused from the framework. In this way, the de- 
sign/programming effort involved in the construction of multi-agent systems is greatly re- 
duced. 

Unlike other tools, Brainstorm/J is able to support many types of agents in diverse 
application domains, since it is possible to extend and adapt the framework by means of 
subclassification. 

Future research on Brainstorm/J will integrate single-agent learning and multi-agent 
learning into the framework by materializing the learner component prescribed by Brain- 
storm. In addition a methodology for designing and programming agents with Brainstorm/J 
should be developed. 
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